Some thoughts on the interface here...

Currently there are two things that influence the choice of algorithm: the selection of countFunction, and whether segmenter is set or not. Wondering if it would be simpler to have explicit functions for graphemes as well as characters and words? In that case passing countType: "graphemes" would be syntactic sugar for passing countFunction: countFunctions.graphemes and the same goes for "characters" and "words".

It also seems slightly inconsistent that if you pass countType: "words" with a custom function, we pass through a segmenter that can do word segmentation, but if you don't pass the custom function, it doesn't use the segmenter.

Maybe if the interface is simplified to fn(text) the segmenter could be an internal implementation detail?

Yeah, I partly did this because Intl.Segmenter also supports granularity: "word" 😮

So instead of countType: "words" we could keep maxwords but set granularity: "word"

I'll see what feedback comes from the GOV.UK Design System team

Maybe if the interface is simplified to fn(text) the segmenter could be an internal implementation detail?

Yeah, I'm glad you said. I reckon for now let's ditch the static property and keep it all internal, especially with a potential performance cost to creating a new segmenter on every keystroke (hence injecting it in)

Feedback applied, thanks @MatMoore

Regarding word counts via the segmenter, I've messaged @romaricpascal and added a comment as the Unicode Default Word Boundary Specification varies quite significantly from /\S+/g

For example, consider this phrase:

My mother-in-law—Wait, what?

It matches only 3 words currently:

["My", "mother-in-law—Wait,", "what?"]

Yet using the segmenter with granularity: "word" it matches 6 words:

["My", "mother", "in", "law", "Wait", "what"]

Yeah, I'm glad you said. I reckon for now let's ditch the static property and keep it all internal, especially with a potential performance cost to creating a new segmenter on every keystroke (hence injecting it in)

Yeah I figured we wouldn't want to instantiate one each call. The way you've done it is what I was imagining.

That unicode word boundary spec seems like a cleaner way to do word counting if we were implementing from scratch, but I guess it's a potentially breaking change so maybe it's not worth it if we're keeping maxwords. Are we going to wait for the govuk implementation before we merge this?

Thanks. Yeah it'll be discussed at their next dev catch up

What we know is that they've proposed for maxwords to be deprecated

We could take the countType option as an opt-in to use segmenter. But as this comment mentions that might mean upgrading /\S+/g to a better word boundary regex for older browsers that lack support

They've not had chance to discuss anything character count related other than this comment:

• Add character count Intl.Segmenter support with customisable count function alphagov/govuk-frontend#6995 (review)

But that applies to #1899 primarily

For this PR all count functions now use the same interface so it's ready for another review